Refresh of the binding tables between data-link-layer and network-layer addresses on mobility in a data center environment

ABSTRACT

A method for assisting communication of a source host upon movement from a first Data center (DC) to a second DC is disclosed. The method includes identifying that the source host has moved from the first DC to the second DC, ensuring that packets identifying a source as the source host in the second DC are copied to a control plane network element, and, for a first destination host identified in a first packet copied to the control plane network element and identified as a host that is not in the second DC, updating an Address Resolution Protocol (ARP)/Neighbor Discovery Protocol (NDP) cache of the source host by sending, to the source host, a first ARP message/unsolicited neighbor advertisement specifying a Media Access Control (MAC) address of an edge router associated with the source host in the second DC as a destination MAC address for the first destination host.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.16/941,243 filed on Jul. 28, 2020, which is a continuation of U.S.patent application Ser. No. 15/990,340 filed on May 25, 2018, which is acontinuation of U.S. patent application Ser. No. 14/878,716 filed onOct. 8, 2015, which in turn claims priority to India Patent Applicationfiled on Jul. 23, 2015, IN Application Serial No. 3793/CHE/2015, thecontents of which are incorporated herein by reference in theirentireties.

TECHNICAL FIELD

This disclosure relates in general to the field of computer networkingand, more particularly, to techniques for Address Resolution Protocol(ARP) and Neighbor Discovery Protocol (NDP) cache refresh on mobility indata centers.

BACKGROUND

Data centers are increasingly used by enterprises for effectivecollaboration and interaction and to store data and resources. A typicaldata center network contains myriad network elements, including hosts,load balancers, routers, switches, etc. The network connecting thenetwork elements provides secure user access to data center services andan infrastructure for deployment, interconnection, and aggregation ofshared resources as required, including applications, hosts, appliances,and storage. Improving operational efficiency and optimizing utilizationof resources in such data centers are some of the challenges facing datacenter managers. Data center managers want a resilient infrastructurethat consistently supports diverse applications and services andprotects the applications and services against disruptions. A properlyplanned and operating data center network provides application and dataintegrity and optimizes application availability and performance.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIGS. 1A and 1B are simplified schematic diagrams illustrating a networkcomprising multiple DC's and illustrating a source host before and aftera move, respectively, according to some embodiments of the presentdisclosure;

FIGS. 2A and 2B are simplified schematic diagrams illustrating ARPentries of an ARP table on a host before and after a move, respectively,according to some embodiments of the present disclosure;

FIG. 3 is a simplified schematic diagram illustrating a functional viewof an ARP refresh logic, according to some embodiments of the presentdisclosure;

FIG. 4 is a flowchart of method steps illustrating a process forassisting communication of a source host upon movement from a first datacenter to a second data center, according to some embodiments of thepresent disclosure;

FIG. 5 is a flowchart of method steps illustrating refresh of ARP cacheentries on a newly moved source host following lenient mode ofoperation, according to some embodiments of the present disclosure;

FIG. 6 is a flowchart of method steps illustrating refresh of ARP cacheentries on a newly moved source host following strict mode of operation,according to some embodiments of the present disclosure; and

FIG. 7 is a flowchart of method steps illustrating identification of anew host move, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

One aspect of the present disclosure provides a method for assistingcommunication of a source host (e.g. a host denoted “B” in the presentFIGUREs) upon movement from a first data center (DC) (e.g. a DC denoted“East DC” in the present FIGUREs) to a second DC (e.g. a DC denoted“West DC” in the present FIGUREs). The method includes identifying thatthe source host (“B”) has moved from the first DC (“East DC”) to thesecond DC (“West DC”). The method also includes ensuring that packets(or, in some embodiments, packet headers) identifying a packet source asthe source host in the second DC are selectively copied to a networkelement, e.g. a control plane network element, e.g. to a list processing(LISP) control plane network element. Copying the packets allowssnooping the packets outgoing from the source host after the move. For afirst destination host identified in a first packet copied to thecontrol plane network element (i.e., a snooped packet) and identified asa host that is not in the second DC (i.e. a destination host that isremote to the source host after the move of the source host, e.g. a hostdenoted “C” in the present FIGUREs), the method includes refreshing(i.e. updating) an Address Resolution Protocol (ARP) cache of the sourcehost (i.e. updating an ARP entry for the first destination host withinthe ARP cache of the source host). The ARP cache of the source host isupdated by sending, to the source host, a first ARP message (e.g. amessage referred to herein as a “gratuitous ARP message”) specifying adata link layer address of an edge router (“S1”) associated with (i.e.default for) the source host in the second DC as a destination data linklayer address for the first destination host. In some embodiments, datalink layer addresses described herein may comprise Layer 2 (L2)addresses of the Open System Interconnect (OSI) model, such as e.g.Media Access Control (MAC) addresses, while network layer addressesdescribed herein may comprise Layer 3 (L3) addresses of the OSI model,such as e.g. Internet Protocol (IP) addresses.

While the above-described aspect relates to update of ARP cache, anInternet Protocol version 4 (IPv4) mechanism, another aspect of thepresent disclosure provides a similar method for assisting communicationof a source host upon movement from a first DC to a second DC, but inthe context of Internet Protocol version 6 (IPv6), where a NeighborDiscovery Protocol (NDP) cache, referred to as “neighbor cache,” mayneed to be updated. The method includes identifying that the source hosthas moved from the first DC to the second DC, ensuring that packetsidentifying a source as the source host in the second DC are copied tothe NDP refresh logic, and for a first destination host identified in afirst packet copied to the NDP refresh logic and identified as a hostthat is not in the second DC, updating a neighbor cache of the sourcehost by sending, to the source host, an unsolicited neighboradvertisement message specifying a data link layer address of an edgerouter associated with the source host in the second DC as a destinationdata link layer address for the first destination host.

Since embodiments of the methods described herein involve update of anARP cache in IPv4 or a neighbor/NDP cache in IPv6, a functional entityperforming embodiments of these methods will be referred to in thefollowing as an “ARP/NDP refresh logic.” Such a functional entity couldbe implemented within any network element or distributed among aplurality of network elements associated with the first and/or secondDCs, but typically is implemented in a first hop router of a DC to whichthe source host has moved. In practice, ARP/NDP refresh logic ispreferably implemented within each first hop router of all DCs, toensure that ARP/NDP cache of a source host is properly updated upon amove of the source host to any of the DCs.

As will be appreciated by one of ordinary skill in the art, aspects ofthe present disclosure, in particular the functionality of the ARP/NDPrefresh logic described herein, may be embodied as a system, a method ora computer program product. Accordingly, aspects of the presentdisclosure may take the form of an entirely hardware embodiment, anentirely software embodiment (including firmware, resident software,micro-code, etc.) or an embodiment combining software and hardwareaspects that may all generally be referred to herein as a “circuit,”“module” or “system.” Functions described in this disclosure may beimplemented as an algorithm executed by a processor, e.g. amicroprocessor, of a computer. Furthermore, aspects of the presentdisclosure may take the form of a computer program product embodied inone or more computer readable medium(s), preferably non-transitory,having computer readable program code embodied, e.g., stored, thereon.In various embodiments, such a computer program may, for example, bedownloaded to the existing devices and systems (e.g. to the existingnetwork elements such as the existing routers, switches, various controlnodes, etc.) or be stored upon manufacturing of these devices andsystems.

Example Embodiments

While details of certain embodiments of the present invention aredescribed with reference to ARP, i.e. an IPv4 mechanism, these teachingsare equally applicable, with modifications that would be apparent to aperson of ordinary skill in the art based on the descriptions providedherein, to NDP in IPv6 neighbor discovery.

Exemplary Setting for Mobility in Data Centers

For purposes of illustrating the techniques implemented by ARP refreshlogic, it is important to understand the activities that may be presentin a typical network environment. The following foundational informationmay be viewed as a basis from which the present disclosure may beproperly explained. Such information is offered for purposes ofexplanation only and, accordingly, should not be construed in any way tolimit the broad scope of the present disclosure and its potentialapplications.

An exemplary network in which embodiments of the present disclosure canbe implemented may be viewed as a collection of data centers, where a“data center” (DC) typically refers to a set of network elements, suchas e.g. routers, switches, and controllers, as well as hosts connectedthereto, that may communicate with one another by routing packets usinga common instance of a routing protocol, typically an interior gatewayprotocol (IGP), and by referring to certain common metrics to define arouting domain governed by the particular instance of the routingprotocol. It is possible to use a variety of IGPs, such as e.g. RoutingInformation Protocol (RIP), Enhanced Interior Gateway Routing Protocol(EIGRP), Open Shortest Path First (OSPF) protocol, interior BGP (iBGP)and Intermediate System-to-Intermediate System (IS-IS) protocol, andsometimes several sets of metrics within a DC to implement the instanceof a routing protocol that defines the scope of a data center. It isalso possible to use an EGP, such as e.g. external BGP (eBGP), toinstantiate the routing domain defining the scope of a data center.Typically, the network elements of a DC are under a single technicaladministration. Segregation into different DC's allows definingadministrative authorities and routing policies of different entities,e.g. of different organizations or different parts of a singleorganization.

Externally, network elements and hosts of different DC's may communicatewith one another by routing packets using an Exterior Gateway Protocol(EGP), such as e.g. using the current Internet standard as BGP Version 4(BGP-4) defined in RFC 4271. Of course, all other exterior gatewayprotocols may also be used and are within the scope of the presentdisclosure.

Another way to look at DCs is to consider that network elements andhosts that may communicate with one another using their respective datalink layer addresses (e.g. MAC addresses) belong to one DC and arereferred to as “local” to one another. In contrast, if in order for e.g.a first host to communicate with a second host, the first host has touse a data link layer address of its default first hop router, then thesecond host is in another DC and is referred to as “remote” to the firsthost.

In various embodiments, a “host” may be or comprise, by way ofnon-limiting example, any device providing storage, network, or/andcomputing resource in a data center. Examples of hosts include, but arenot limited to, a computer, workstation, server, mainframe, virtualmachine (whether emulated or on a “bare-metal” hypervisor), container,embedded computer, embedded controller, embedded sensor, personaldigital assistant, laptop computer, cellular telephone, IP telephone,smart phone, tablet computer, convertible tablet computer, computingappliance, network appliance, receiver, wearable computer, handheldcalculator, or any other electronic, microelectronic, ormicroelectromechanical device for processing and communicating data.

FIG. 1A is a simplified schematic diagram illustrating a network 100comprising multiple DC's, according to some embodiments of the presentdisclosure. In the example of FIG. 1A, two DC's are illustrated as afirst DC 110, denoted as “East DC” and a second DC 120, denoted as “WestDC.”

The first DC 110 includes routers 112 a-112 f, each of which may beoperatively coupled to at least one other node within the first DC 110as shown with solid lines between some of the routers 112 a-112 f Thelines between some of the routers 112 a-112 f may be viewed to representexchange of packets according to one or more IPGs of the first DC 110,such as e.g. iBGP.

Similarly, the second DC 120 includes routers 122 a-122 g, each of whichmay be operatively coupled to at least one other node within the secondDC 120 as shown with solid lines between some of the routers 122 a-122g. The solid lines between some of the routers 122 a-122 g may be viewedto represent exchange of packets according to one or more IGPs of thesecond DC 120, such as e.g. iBGP.

Routers in one DC that are configured to communicate with routers inother DC's are referred to as “edge routers”, while routers in one DCthat are only configured to communicate with other routes in the same DCare referred to as “core routers.” In the illustration of FIG. 1A,routers 112 a, 112 b, 112 e, and 112 f are edge routers, while routes112 c and 112 d are core routers of the first DC 110, while, for thesecond DC 120, routers 122 a, 122 b, 122 d, and 122 f are edge routersand routes 122 c, 122 e, and 122 g are core routers.

Each of the edge routers is configured to communicate, via e.g. externalprotocol 140 such as e.g. eBGP, with one or more edge routers in anotherDC. As an illustrative example, the edge routers may be service nodes(e.g. L3VPN, Layer 2 Virtual Private Network (L2VPN) endpoints) thatexchange service state via BGP and Label Distribution Protocol (LDP).

In various implementations of embodiments of the present disclosure, aDC may be considered as a physical leaf/spine underlay distributedfabric on which a logical network of hosts is provided as an overlaynetwork. In such implementations, “leaf nodes” may be analogous to whatis illustrated in FIG. 1A as edge routers, and “spine nodes” may beanalogous to what is illustrated in FIG. 1A as core routers.

Each leaf node in the topology may be a leaf switch that houses one ormore network elements, such as e.g. physical servers. Though notillustrated in FIG. 1A, a physical server associated with a leaf switchof each leaf node may be housed in a rack unit or “rack.” Additionalphysical servers may also be housed in the rack. Leaf nodes areresponsible for managing communications (e.g., routing and forwarding)originating from and destined for physical servers (and virtual machinesand virtual switches hosted by the physical servers) in the rack. Hence,a term “top-of-rack” (ToR) is sometimes ascribed to leaf nodes. Eachleaf node may act as a gateway from a Layer 2 network of a DC (e.g.Ethernet) onto the fabric 140 which operates at Layer 3. Therefore,sometimes leaf nodes are also described as “first hop routers” and, inthe following, the terms first hop router, edge router, leaf node, andToR switch may be used interchangeably.

It is appreciated that any number of leaf switches and spine switchesmay be present in a DC. Furthermore, while a physical leaf/spinetopology with tenant overlay networks is used as an example, any networkarchitecture with a physical underlay network and physical and/orlogical overlay networks would be consistent with techniques presentedherein. In addition, discussions herein are applicable to any IP fabricand presence of the spine nodes is entirely optional. For example,without spine nodes, the leaf nodes could be connected through a fullmesh topology.

One or more hosts may be connected to the leaf and/or spine nodes of aDC, shown in FIG. 1A as hosts 130, in particular as hosts B and C in thefirst DC 110 and host A in the second DC 120, although it is appreciatedthat any number of hosts may be present in (i.e. connected to) a DC.

In some embodiments, hosts 130 may include virtual switches and virtualmachines (“VMs”) that may be created and run on a physical serverconnected to each leaf node on top of a hypervisor (not shown in theFIGUREs). The virtual switches may be configured to managecommunications of VMs in particular virtual networks and/or subnetworks(“subnets”) and may be embodied by software stored and executed on thecorresponding physical server connected to a leaf node, thus performingfunctions of a physical switch device. Similarly, the VMs may besoftware stored and executed on the corresponding physical serversconnected to the leaf nodes and configured to exchange communicationswith other VMs. However, embodiments of the present disclosure are notlimited to VM hosts and virtual switches. For example, in other typicalembodiments, the hosts may include containers and bare-metal workloadhosts (i.e. workloads that are not running a VM) that preserve their IPaddress as the application moves the workloads (example includeclustered applications such as oracle RAC, etc.).

Address Resolution Protocol

Address Resolution Protocol (ARP) refers to a telecommunication protocolused for resolution of OSI L3 addresses (i.e. network layer addresses)into OSI L2 addresses (i.e., data link layer addresses). Converting anetwork layer address, such as e.g. an IPv4 address, to a physicaladdress such as e.g. an Ethernet address, also referred to as a MACaddress, provides a critical function in multiple-access networks. Whileembodiments of the present disclosure are described with reference to IPaddresses as network layers addresses and MAC addresses as link layeraddresses, ARP may be implemented with many combinations of network anddata link layer technologies, such as IPv4, Chaosnet, DECnet and XeroxPARC Universal Packet (PUP) using IEEE 802 standards, FDD, X.25, FrameRelay, and Asynchronous Transfer Mode (ATM), all of which are within thescope of the present disclosure.

ARP is used to populate ARP table (also referred to as “ARP cache”) in adevice with ARP entries, each entry comprising a network layer addressand a data link layer address of one other device with which the firstdevice is or may be communicating. Typically ARP entries are kept in adevice for some period of time, as long as it is being used.

Problems Associated with Host Mobility Between Data Centers

For simplicity, embodiments of the disclosure are further described withreference to the host B moving from the East DC to the West DC, the hostB associated with a default gateway in the East DC in the form of theedge router 112 b (denoted as “D1” in FIG. 1A) and having a defaultgateway in the West DC in the form of the edge router 122 b (denoted as“S1” in FIG. 1A). However, analogous descriptions are applicable to anyother network elements of the network 100. FIG. 1A illustrates host Bbefore the move (i.e., host B is in the East DC), while FIG. 1Billustrates host B after the move (i.e., host B moved from the East DCto the West DC). Except for the difference of the location of host B,descriptions provided above fore FIG. 1A are applicable to FIG. 1B and,therefore, in the interests of brevity, are not repeated here.

Consider a situation of FIG. 1A, where host B is having a conversation(i.e. exchanging data) with hosts A and C. In such a case, an ARP cacheon host B will include ARP entries for hosts A and C, as shown in FIG.2A. Since host B will use this ARP cache to send data to hosts A and C,host B is referred to as a “source host” and hosts A and C are referredto as “destination hosts.” Because in the situation of FIG. 1A, hosts Band C are within the same DC (i.e. within the same subnet) andcommunicate with each other using intra-domain protocols, the ARP cacheon host B will indicate MAC address of host C within the East DC subnet(indicated as “MAC-C” in FIG. 2A). Because in the situation of FIG. 1A,hosts B and A are within different DCs (i.e. within different subnets)and communicate with each other using inter-domain protocols, the ARPcache on host B will indicate MAC address for host A as a MAC address ofa first hop router (default gateway) associated with host B in the EastDC subnet, e.g. router D1 (the MAC address indicated as “MAC-D1” in FIG.2A).

Consider now that host B moves to another DC, a situation illustrated inFIG. 1B with host B moving to the West DC. Eventually, ARP entries onhost B may get refreshed to reflect the move. Until this happens, B willcontinue to use addresses in accordance with the entries as shown inFIG. 2A to send packets to hosts A and B. However, as a result of themove, A is no longer a remote host to host B and C is no longer a localhost to host B, and, therefore their L2 addresses in the ARP cache onhost B are incorrect and traffic sent from host B to hosts A and C willget black-holed (i.e. will not reach the desired destination hosts A andC).

Existing Solutions to Enable Communication in Presence of Host MobilityBetween Data Centers

Various solutions exist to solve the ARP cache problem in a host thathas moved to a different data center.

One such solution relies on the use of an L2 extension between two datacenters. However, one drawback of such a solution is an implicitrequirement to have a technology such as OTV, VPLS, or direct linkbetween two data centers.

Another solution relies on deployment of Mobile IP. However, in case ofmobile IP, all traffic has to traverse the home agent (home data center)before being forwarded to the correct data center. Such a solutionresults in traffic “tromboning” and increased latency.

Yet another solution relies on presence of a virtual switch that may beconfigured to re-write MAC addresses in packets sent by the moved sourcehost with MAC addresses that reflect the move. However, this solutionrequires a presence of a virtual switch that can re-write the packetheaders with correct MAC addresses and requires additional processingresources for performing the re-write for all packets.

Proposed Solution to Enable Communication in Presence of Host MobilityBetween Data Centers

Embodiments of the present disclosure aim to provide a technique forassisting communication (in particular, enabling continuation ofexisting communications) of a source host upon a move from one datacenter to another data center in a manner that improves on or eliminatesat least some of the problems of the existing solutions. To that end, amethod is provided that allows refresh of an ARP table on a moved host.Continuing with the example of a move of host B as illustrated in FIGS.1A and 1B, as a result of performing the ARP refresh method as describedherein, the ARP entries on host B for destination hosts A and C will beupdated as illustrated in FIG. 2B.

FIG. 3 is a simplified schematic diagram illustrating an ARP refreshlogic 310, according to some embodiments of the present disclosure. Asshown, the ARP refresh logic 310 may include at least one processor 312and at least one memory element 314, along with any other suitablehardware to enable its intended functionality of ARP refresh on a movedhost. Various repositories may be associated with the ARP refresh logic310, including, but not limited to, an Access Control List (ACL)repository 320 and/or an Adjacency Manager (AM) 330, described ingreater detail below.

Even though the ARP refresh logic 300 is not illustrated in the networksillustrated in FIGS. 1A and 1B, the ARP refresh logic 300 may beimplemented as or in a network element, e.g. a control plane networkelement, or distributed over a number of network elements of the network100. In some embodiments, the ARP refresh logic 300 may be includedwithin at least some, preferably all, leaf nodes (i.e. first hoprouters) of each DC, e.g. within the leaf nodes D1, D2, S1, and S2.

In various embodiments, elements of FIGS. 1A-1B and 3 may be coupled toone another through one or more interfaces employing any suitableconnections (wired or wireless), which provide viable pathways fornetwork communications. Additionally, one or more of these elements ofFIGS. 1A-1B and 3 may be combined, divided, or removed from thearchitecture based on particular configuration needs. Networkenvironment 100 and ARP refresh logic 300 may include a configurationcapable of transmission control protocol/internet protocol (TCP/IP)communications for the transmission and/or reception of packets in thenetwork. Network environment 100 and ARP refresh logic 300 may alsooperate in conjunction with a user datagram protocol/IP (UDP/IP), anyother suitable protocol, or any suitable combination thereof whereappropriate and based on particular needs.

Furthermore, in various embodiments, various functionalities describedherein may be offloaded to external devices, not specifically describedherein. For example, snooped packets described herein could be routed toan external module (e.g. F3 module in N7K switch by Cisco), GARP andPARP messages described below could be offloaded to an F3 ACP Engine,etc.

FIG. 4 is a flowchart 400 of method steps illustrating an ARP refreshprocess for assisting communication of a source host upon movement froma first DC to a second DC, according to some embodiments of the presentdisclosure. While the method steps illustrated in FIG. 4, as well as themethod steps illustrated in FIGS. 5 and 6 described below, are explainedwith reference to elements shown in FIGS. 1A-1B and 3, and, inparticular, with reference to the example of host B moving from East DCto West DC, described above, any network elements configured to performthese steps are within the scope of the present disclosure.

The method 400 may begin with step 402 where the ARP refresh logicidentifies that a host has moved from one DC to another DC, e.g. host Bmoved from East DC to West DC, as explained above. To that end, the ARPrefresh logic 300 may be configured to carry out any of the existingmethods as known in the art for identifying a “NEW” host move, such ase.g. new source MAC learning, Neighbor detection, or snooping ReverseARP (RARP) messages sent by moved host. Alternatively or additionally,the ARP refresh logic 300 may be configured to carry out a method foridentifying a new host move as illustrated in FIG. 7 and describedbelow.

As a part of identifying that the host has moved, the ARP refresh logic300 learns the new MAC address of the newly moved host, i.e. the MACaddress of source B in the West DC, MAC-B.

In response to (i.e. triggered by) the identification of a new hostmove, the ARP refresh logic 300 is configured to ensure, in step 404,that all packets sent by the newly moved host B are copied to it. Inother words, step 404 ensures that the ARP refresh logic 300 may “snoop”the packets sent by the newly moved host of step 402. As described ingreater detail below, snooping is done in order to learn IP addresses ofall of the hosts with which the newly moved host is communicating, i.e.to learn IP addresses of all destination hosts for the newly movedsource host B.

In one embodiment, snooping of packets may be achieved by changingAccess Control List (ACL) of a default edge router associated with thenewly moved host in the data center that the host moved to. ACLs aretypically maintained in routers in order for the routers to performpolicy based routing. Each entry in an ACL defines an access ruledefining particular type of traffic and which action is to be performedon the traffic. Typically the actions include PERMIT and DENY,permitting or denying forwarding of the packet. ACLs may be used tosnoop packets by specifying an action to copy a packet to a particularpredefined location (typically in addition to the PERMIT or DENYaction). A particular access rule (i.e. a particular entry of the ACL)that applies to a particular data packet received or transmitted by arouter may be ascertained from information in one or more headers of thepacket. If two different access rules apply to a given data packet, arouter is typically configured to take the action of the rule that ismore specific.

Consider that the default router for host B after the move is the edgerouter S1. In such a case, ACL of S1 is changed in step 404. Morespecifically, in step 404, the ARP refresh logic 300 may be configuredto create an ACL entry, in S1, specifying a source of the packet aseither a network layer of host B or a data link layer address of host Bin West DC, and specifying the “action” of the ACL entry as copying thepacket to the ARP refresh logic. For example, the ARP refresh logic 300may be configured to create an ACL entry to match the newly learned MACSource-MAC (B's Source MAC), Destination NOT router-MAC, rate-limit andcopy the packets to LISP control plane. Alternatively, the ARP refreshlogic 300 may be configured to create an ACL entry to match the IPaddress of the moved source host (B's Source IP), rate-limit and copythe packets to LISP control plane. In this manner, ACL may beadvantageously used for snooping outgoing packets from the newly movedsource host.

In an embodiment, the ARP refresh logic 300 may be configured to ensurethat the ACL entry created in step 404 expires after a certain timeperiod (either predefined, or dynamically determined by the ARP refreshlogic based on various criteria, e.g. based on network load in general,the amount of communications exchanged by host B, etc.), e.g. by settinga timer to clear that ACL entry. In this manner, outgoing packets fromthe newly moved source host B stop being snooped after a certain timeperiod. The time period should be set such as to reasonably allowlearning of all destination hosts with which the newly moved source hostis communicating and updating ARP entries of the newly moved source hostaccordingly.

Thus, ACL may be used to copy packets to the ARP refresh logic. The ARPrefresh logic may then analyze the copied packets and update the ARPcache of the newly moved host B accordingly. In particular, for eachdestination host identified in the copied packets as remote to the newlymoved source host B, the ARP refresh logic is configured to send agratuitous ARP (GARP) message to the newly moved host, the GARP messagespecifying a data link layer address of the default edge routerassociated with the newly moved source host in the DC that the hostmoved to as a destination data link layer address to use for the remotedestination host (step 406 shown in FIG. 4). For the scenario consideredabove, this means that, in step 406, the ARP refresh logic would send aGARP to host B specifying that the MAC address to use for destinationhost C should be the MAC address of the default edge router S1 that isassociated with host B in West DC. In response to receiving such a GARPmessage, host B will update its ARP cache entry for the remotedestination host C accordingly (i.e. the entry in the ARP table of hostB for the destination host C will contain information indicated for thedestination host C in FIG. 2B). Therefore, the ARP refresh logic sendingsuch a GARP message to the newly moved source host may be considered asan action causing ARP cache update of the newly moved host (inparticular, update of the ARP entry for that particular destinationhost). If there are other remote destination hosts that host B iscommunicating with, similar GARP messages are sent for those destinationhosts as well, and ARP entries on host B for those destination hosts areupdated in a similar manner.

In addition to updating the MAC addresses of the remote destinationhosts, the ARP refresh logic may also be configured to update ARP cacheentries on the newly moved source host for local destination hosts aswell, as needed, as described in greater detail below (not shown in FIG.4).

Furthermore, in an embodiment that is also not shown in FIG. 4, once anARP cache entry for a particular destination host (either remote orlocal) has been updated (or determined to not need an update, whichcould be the case for local destination hosts, as described in greaterdetail below), the ARP refresh logic may be configured to create anotherentry in the ACL of the edge router associated with the newly movedsource host (i.e. in the edge router S1). Such a new ACL entry wouldspecify the source of a data packet as described for the first ACL entryabove, but also specify the destination of a data packet with an IPaddress of the destination host for which the ARP cache entry has beenupdated. The action on such an ACL entry would be to PERMIT the matchingpackets. Because such an ACL entry would be more specific for packetsgoing from host B to such a specific destination host, the action willtake precedence over the first ACL entry (step 404) and packets fromhost B to this destination host will no longer be copied to the controlplane. Such an embodiment provides an optimization reducing controlplane traffic by preventing packets from being copied to the controlplane network element after an ARP entry for the destination host hasbeen updated in the newly moved source host.

Update of the ARP entries on the newly moved source host for both theremote and the local destination hosts may be performed in two differentmanners, illustrated in FIGS. 5 and 6, respectively. One manner isreferred to herein as a “lenient mode of operation” and the other manneris referred to herein as a “strict mode of operation.”

FIG. 5 is a flowchart 500 of method steps illustrating refresh of ARPcache entries on a newly moved source host following lenient mode ofoperation, according to some embodiments of the present disclosure.

The method 500 may be considered as a continuation of the method 400illustrated in FIG. 4 (therefore, all of the discussions provided abovein association with FIG. 4 are applicable to the method 500 as well). Inparticular, the method 500 may be viewed as method steps performed afterstep 404 illustrated in FIG. 4 and incorporating the step 406illustrated in FIG. 4. Continuing with the example of host B moving fromEast DC to West DC, once the ARP refresh logic 300 ensured that packetssent by the newly moved host B to all of the destination hosts arecopied to it (step 404), the ARP refresh logic may be configured toperform method steps 500 for at least some, but preferably each, of thecopied packets. In step 502, the ARP refresh logic extracts adestination IP address and MAC address from a particular copied packetbeing evaluated. In step 504, the ARP refresh logic then checks whetherthe extracted destination IP address is present in a list of destinationIP addresses indicated as IP addresses of hosts that arewithin/connected to the West DC.

In an embodiment, such a list could be provided in a form of a so-calledadjacency manager (AM) table maintained by the edge router associatedwith the newly moved host B (i.e. by the edge router S1). An AM tabletypically includes matching of network layer addresses to data linklayer addresses for all of the hosts within a DC. Typically, each edgerouter maintains such an AM table and uses it to route packets for hostsfor which the edge router is a default router. Thus, an AM table may beconsidered as an ARP cache of an edge router associated with the newlymoved host (for the example considered herein—ARP cache of the edgerouter S1). While further discussions will be provided with reference tosuch an AM table, embodiments of the present disclosure are not limitedto such implementation and cover the use of any similar listingmaintained by any entity or distributed over a number of entities withinor associated with a particular DC.

If, in step 504, the ARP refresh logic determines that the extracteddestination IP address for the copied packet is not present in the AMtable of West DC, then it means that the destination host identified bythis IP address is not in West DC, i.e. that the destination host is aremote host (with respect to the newly moved host B). In this case, themethod proceeds to step 506 that is applicable to remote destinationhosts, where the ARP refresh logic sends a GARP message as described forstep 406 of FIG. 4 (in the interests of brevity, that description is notrepeated here).

For example, consider that, in step 502, a copied packet sent from hostB to host C is being evaluated. In such a case, the IP address extractedfrom the copied packet will be “IP-C” and the MAC address extracted fromthe copied packet will be “MAC-C” because, before the move to West DC,host B used to be local to host C (i.e. host B did not have to use itsdefault router D1 to reach host C but could just use the MAC address ofhost C, MAC-C). In step 504, the ARP refresh logic will determine thatthe extracted destination IP address is not in the AM table of the WestDC, because host C is not in the West DC host C is in the East DC).Therefore the method will proceed to step 506, where the ARP logic willsend a GARP message to the host B causing an update of the ARP entry forhost C on host B where a new MAC address for host C will be the MACaddress of the default first hop router associated with host B in WestDC (i.e. “MAC-S1”). Such a change will properly reflect that, after themove, hosts B and C are remote hosts and host B has to send data to hostC by going via a default first hop router of host B (i.e. router S1).

Returning back to the method of FIG. 5, if, in step 504, the ARP refreshlogic determines that the extracted destination IP address for thecopied packet is present in the AM table of West DC, then it means thatthe destination host identified by this IP address is in West DC, i.e.that the destination host is a local host (with respect to the newlymoved host B). In this case, the method proceeds to step 508, where theARP refresh logic then checks whether the extracted destination MACaddress is present in a list of destination MAC addresses indicated asMAC addresses of hosts that are within/connected to the West DC.Typically, this information will be in the same table as the AM tabledescribed above (i.e., a single table includes associations of IPaddresses and MAC addresses for all local hosts of a particular DC).However, implementations of a separate listing with MAC addresses (anydata link layer addresses) belonging to a particular DC is also withinthe scope of the present disclosure.

In particular, in step 508, the ARP refresh logic checks whether the MACaddress stored in the AM for a host associated with the IP address thatmatches the destination IP address extracted from a copied packetmatches the MAC address extracted from the copied packet. If these twoMAC addresses match, then there is no need to update the ARP cache entryon the newly moved host B for this local destination host, as shown witha dashed box “NO NEED TO UPDATE” in FIG. 5. If these two MAC addressesto not match, then, in step 510, the ARP cache logic is configured togenerate and send a proxy ARP (PARP) message to the newly moved host,the PARP message indicating that the destination MAC address to use forthis destination host should be the MAC address stored in the AM table.

For example, consider that, in step 502, a copied packet sent from hostB to host A is being evaluated. In such a case, the IP address extractedfrom the copied packet will be “IP-A” and the MAC address extracted fromthe copied packet will be “MAC-D1” because, before the move to West DC,host B used to be remote to host A and had to use its default router D1to reach host A. In step 504, the ARP refresh logic will determine thatthe extracted destination IP is in the AM table of the West DC, becausehost A is in the West DC. Therefore the method will proceed to step 508,where the ARP logic will further determine that the MAC addressextracted from the copied packet (i.e. “MAC-D1”) does not match the MACaddress stored in the AM table of the West DC as associated with the IPaddress of host A because the AM table will indicate “MAC-A” as the MACaddress of host A. Therefore, the method will proceed to step 510, wherethe ARP logic will send a PARP message to the host B causing an updateof the ARP entry for host A on host B where a new MAC address for host Awill be the MAC address of host A in West DC (i.e. “MAC-A”). Such achange will properly reflect that, after the move, hosts A and B arelocal hosts and may communicate by using its local MAC addresses insteadof going via a default first hop router.

Thus, in response to receiving a PARP message of step 510, host B willupdate its ARP cache entry for the local destination host A accordingly(i.e. the entry in the ARP table of host B for the destination host Awill contain information indicated for the destination host A in FIG.2B). Therefore, the ARP refresh logic sending such a PARP message to thenewly moved source host may be considered as an action causing ARP cacheupdate of the newly moved host (in particular, update of the ARP entryfor that particular destination host). If there are other localdestination hosts that host B is communicating with, similar PARPmessages are sent for those destination hosts as well, and ARP entrieson host B for those destination hosts are updated in a similar manner.

The lenient mode described above relies on the assumption that IP-to-MACconversion entries in the list maintained by the edge routers of a DCare up to date and correct. When this is not the case, as e.g. canhappen if another host in communication with host B moves as well,substantially simultaneously with the move host B, the communicationwill fail until the mapping systems are updated. The strict modedescribed below does not rely on such an assumptions.

FIG. 6 is a flowchart 600 of method steps illustrating refresh of ARPcache entries on a newly moved source host following strict mode ofoperation, according to some embodiments of the present disclosure.

The method 600 may be considered as a continuation of the method 400illustrated in FIG. 4 (therefore, all of the discussions provided abovein association with FIG. 4 are applicable to the method 600 as well). Inparticular, the method 600 may be viewed as method steps performed afterstep 404 illustrated in FIG. 4 and incorporating the step 406illustrated in FIG. 4. Continuing with the example of host B moving fromEast DC to West DC, once the ARP refresh logic 300 ensured that packetssent by the newly moved host B to all of the destination hosts arecopied to it (step 404), the ARP refresh logic may be configured toperform method steps 600 for at least some, but preferably each, of thecopied packets. In step 602, the ARP refresh logic extracts adestination IP address from a particular copied packet being evaluated.

Once a destination IP address is extracted from a copied packet, then,in contrast to the lenient approach illustrated in FIG. 5, the ARPrefresh logic does not check whether the extracted IP address is presentin the AM table of the West DC. Instead, the ARP refresh logic initiatesan ARP learning sequence for the extracted IP address of the destinationhost by sending a broadcast (i.e., to the local broadcast domain) ARPrequest for the extracted destination IP address on behalf of the edgerouter associated with the newly moved host B (i.e. on behalf of theedge router S1), shown in FIG. 6 with step 604.

As is known in the art, in general, ARP requests are used as follows.ARP is a protocol that maps IP address to a Data link layer address (MACAddress). That is, it is a method by which any node (e.g. host) on theLAN can dynamically learn the Hardware address of any node on the LAN. Anode (e.g. denoted as IP N1) wishing to learn the Hardware address/MACaddress of another node (e.g. denoted as IP N2) in the network sends outa Broadcast Request with the Target as N2. Since the request isbroadcast, all the nodes in the local broadcast domain will receive thisrequest. However only the node that is identified in the target willsend back a response with its Hardware address (if such a node exists inthe local broadcast domain), usually directly (i.e. unicast) to therequesting node (the host which sent the ARP request). Thus, ARPrequests can be used as a way to probe the local broadcast domain todetermine the presence of a particular host.

If dynamic ARP inspection is enabled on the ports of the switches and/orrouters to which the destination hosts are connected, then step 606 maybe skipped, in which case the ARP cache logic is configured to, uponreceiving a response to the request of step 604, generate and send aPARP (i.e. the proxy ARP) message as described above.

If dynamic ARP inspection is not enabled for the destination hosts (e.g.local hosts), then, as a part of the ARP learning sequence, the ARPrefresh logic also sends an ARP request for the extracted destination IPaddress on behalf of the newly moved host B that sent the copied packetbeing analyzed, shown in FIG. 6 with step 606. In an embodiment, the ARPrequest of step 606 includes a network layer address (“IP-B”) of thesource host as an ARP request sender address, a data link layer addressof the default edge router associated with the newly moved source hostas a source data link layer address of the Ethernet header of the ARPrequest, and the network layer address of the destination host extractedfrom the copies packet as a target address of the ARP request (i.e., thesubject of the ARP request). For example, if the copied packet beingevaluated in the method of FIG. 6 is a packet from newly moved host B tohost C, then an ARP request of step 606 will include address IP-B as anIP address of the sender of the ARP request (i.e., host B), addressMAC-S1 as a MAC address of the sender of the ARP request, and extractedIP address of host C (IP-C) as the target of the ARP request. If thecopied packet being evaluated in the method of FIG. 6 is a packet fromnewly moved host B to host A, then an ARP request of step 606 willinclude address IP-B as an IP address of the sender of the ARP request(i.e., host B), address MAC-S1 as a MAC address of the sender of the ARPrequest, and extracted IP address of host A (IP-A) as the target of theARP request.

Even though shown in sequence in FIG. 6, in some embodiments, steps 604and 606 may be performed substantially simultaneously.

In step 608, the ARP refresh logic determines if any ARP request (of theARP requests of steps 604) timed out. ARP request timeout indicates thatthe extracted destination IP address for which the request was sent isnot local (i.e. is not in West DC). In such a case, the ARP refreshlogic establishes that the destination host is a remote host (withrespect to the newly moved host B) and the method proceeds to step 610that is applicable to remote destination hosts, where the ARP refreshlogic sends a GARP message as described for step 406 of FIG. 4 (in theinterests of brevity, that description is not repeated here).

If there is no ARP request time out in step 608, then the ARP cacheentry on host B for the destination host identified by the IP addressindicated in the ARP request messages of steps 604 and 606 is updated asa result of successful ARP request(s), as shown with a dashed box “ARPENTRIES UPDATED AS A RESULT OF SUCCESSFUL ARP REQUEST” in FIG. 6.

For example, consider that, in step 602, a copied packet sent from hostB to host C is being evaluated. In such a case, the IP address extractedfrom the copied packet will be “IP-C”. In step 604, the ARP refreshlogic will send an ARP request with the subject being the extracted IPaddress, IP-C, on behalf of the default first hop router associated withhost B in West DC (i.e. router S1). If no dynamic ARP inspection isenabled, then in step 606 the ARP refresh logic will also send a similarARP request on behalf of the moved host B. In step 608, the ARP refreshlogic will determine that the ARP requests it sent for the targetaddress IP-C timed out, indicating that the destination IP addressextracted from the snooped packet is not local to West DC where host Bhas moved to. Therefore the method will proceed to step 610, where theARP logic will send a GARP message to the host B causing an update ofthe ARP entry for host C on host B where a new MAC address for host Cwill be the MAC address of the default first hop router associated withhost B in West DC (i.e. “MAC-S1”). Such a change will properly reflectthat, after the move, hosts B and C are remote hosts and host B has tosend data to host C by going via a default first hop router of host B(i.e. router S1).

Now, consider that, in step 602, a copied packet sent from host B tohost A is being evaluated. In such a case, the IP address extracted fromthe copied packet will be “IP-A”. In step 604, the ARP refresh logicwill send an ARP request with the subject being the extracted IPaddress, IP-A, on behalf of the default first hop router associated withhost B in West DC (i.e. router S1). If no dynamic ARP inspection isenabled, then in step 606 the ARP refresh logic will also send a similarARP request on behalf of the moved host B. In step 608, the ARP refreshlogic will determine that there is no time out of the ARP request(s)sent for the target address IP-A, indicating that the destination IPaddress extracted from the snooped packet is local to West DC where hostB has moved to. As a result of successful ARP request(s), the ARP entryfor host A on host B will be updated to make sure that the MAC addressfor host A in the ARP cache on host B is the MAC address of host A inWest DC (i.e. “MAC-A”). Such a change will properly reflect that, afterthe move, hosts A and B are local hosts and may communicate by using itslocal MAC addresses instead of going via a default first hop router.

The techniques described herein ensure that the ARP cache of a newlymoved host is updated for the destination addresses that the newly movedhost is communicating with after the move, thereby avoiding trafficblack-holes. The techniques described herein, although specified in thecontext of IPv4 and ARP, are equally applicable to the NeighborSolicitation and Neighbor Advertisement handshake used for NeighborDiscovery in IPv6 networks, as described in greater detail below.

The techniques described herein allow for host mobility without a needfor tromboning the traffic due to the infrastructure provided by theLISP Mapping System and eliminates a need for an L2 extension tointerconnect the data centers, as was done in some prior art approaches.In addition, the techniques described herein do not rely on the use ofdestination MAC re-write by virtual switches, as was also done in someprior art approaches.

FIG. 7 is a flowchart 700 of method steps illustrating identification ofa new host move, according to some embodiments of the presentdisclosure.

As shown with step 702 in FIG. 7, in order to be able to identify newhost moves, the ARP refresh logic, implemented e.g. as the LISP controlplane network element, registers with an appropriate network elementresponsible for providing new MAC learning notifications. In variousembodiments, this may be done e.g. with SISF/L2FIB or L2FM. “SISF”refers to “Switch Integrated Security features”, an implementation whichis responsible for discovering hosts that are local to a site and fordetecting moves into the site and away from it. SISF snoops all relevantprotocol data and builds a cache of IP-MAC binding. “L2FIB” refers to“L2 Forwarding Information Base” providing a list of MAC addresseslearnt on an interface/port, maintained in an RP module in Cisco'sInternetworking Operating System (IDS). “L2FM” refers to “L2 Featuremanager” responsible for maintaining the MAC addresses learnt on a port.This list is maintained in an SUP module in Cisco's NX-OS networkoperating system.

At some point after the registration, the ARP refresh logic 300 willreceive a notification of a newly learned MAC address (step 704). Uponreceiving such a notification, the ARP refresh logic will check whetherany IP addresses are bound to the newly learnt MAC address (step 706),e.g. by checking whether this new learnt MAC has MAC-IP binding presentin AM table or SISF. If there is no such binding found, it confirms anew host move, as indicated in FIG. 7 with a step 708. If there is suchbinding, then the method proceeds to step 710, where the ARP refreshlogic checks whether the IP address bound to the newly learned MACaddress is present in a local End Point Identifier (EID, i.e. an IPaddress, which identifies the end-point/host) database of the LISPcontrol plane. The LISP control plane typically has databases thatmaintain the EIDS to RLOC mappings, both for Local EID/RLOC and RemoteEID/RLOC. If the EID is already present in the Local EID Database, itsignifies that the host is already known, and does not indicate a move,or the actions to be taken after a move are already completed. If the IPaddress is present in the Local EID Database, then the End point isalready known locally, and hence no action is required. Thus, if thedetermination of step 710 is positive, then no action is required foralready present Local EID and the ARP refresh logic can establish thatthere is no new host move (step 712).

If, however, in step 710 is it determined that the IP address bound tothe newly learned MAC address is not present in a local EID, then itconfirms the new host move, as indicated with an arrow from the negativeoutcome of step 710 to step 708.

Optionally, the method 700 may include steps 714 and 716 shown in FIG. 7(dashed boxes and arrows in this FIG. illustrate that the steps areoptional). In step 714, the ARP refresh logic is configured to check ifthe IP address bound to the newly learned MAC address is present inLISP's remote EID-to-RLOC (remote location) cache. If not present, thenit confirms the move, as indicated with an arrow from the negativeoutcome of step 714 to step 708. If present, then the ARP refresh logicmay be configured to log previous location corresponding to EID (step716), and the new host move is confirmed, as indicated with an arrowfrom step 716 to step 708. In other words, consulting Remote EID/RLOCcache (step 714) is an optional step, as irrespective of the result, ahost move is assumed. If the IP address bound to the newly learned MACaddress is present in the Remote EID, it indicates the EID is known asremote before, which is now a new host, and hence moved in to this datacenter, and additionally it is possible to log the fact to indicatewhere it moved from (step 716). If the IP address bound to the newlylearned MAC address is not present, it's a new host that has moved intothe site.

It should be noted that embodiments of the present disclosure are notlimited to LISP. With LISP, it is possible to additionally consult thecache maintained by LISP for detecting Mobility, which is anoptimization. Otherwise it is possible to stop by consulting the ARPcache.

In particular, the identification of a new host move described withreference to FIG. 7 is not limited to LISP. For example, as a person ofordinary skill in the art would readily recognize, references toLocators and EIDs described above are made in the context of LISP.However, as used herein, these terms represent a general notion presentin any overlay technology. For example, in a Virtual Extensible LAN(VXLAN) implementation, equivalent constructs may be found in the formof VXLAN-Tunnel End-Points (VTEPs) and Hosts corresponding to RLOCs andEIDs respectively.

Neighbor Discovery Protocol

As described above, while embodiments of the present invention areexplained herein with reference to ARP, teachings disclosed herein areequally applicable, with modifications that would be apparent to aperson of ordinary skill in the art based on the descriptions providedherein, to NDP in IPv6 neighbor discovery. As is known in the art, theNDP is a mechanism in IPv6 that is equivalent to ARP in IPv4. Inparticular, the Neighbor Solicitation and Neighbor Advertisementexchange in NDP is equivalent to the ARP request and ARP reply exchangeused for IPv4 MAC-IP resolution. Below, analogies between IPv4 elementsdescribed herein and IPv6 elements are provided, which analogies couldbe used as a guidance to implementing teachings of the present inventionin IPv6 networks. Further, some modifications inherent in switching fromthe IPv4 context to IPv6 context are discussed.

Concepts like the network layer addresses, data link layer addresses,ACLs, and Adjacency Manager described herein are common to IPv4 or IPv6embodiments. Further, the “LISP processing control plane networkelement” described herein in IPv4 would be used in a similar manner inNDP of IPv6.

The ARP cache in IPv4 is analogous to the neighbor cache (or NDP cache)in NDP of IPv6.

The “dynamic ARP inspection” in IPv4 is analogous to a dynamicinspection of the IPv6 Neighbor Cache to achieve similar validation ofhost addressing consistency in NDP of IPv6.

The “ARP request” in IPv4 is analogous to an Internet Control MessageProtocol version 6 (ICMPv6) Neighbor Solicitation in NDP of IPv6. Inparticular, a successful Neighbor Solicitation in IPv6 results in ameaningful Neighbor Advertisement from the target host and thesubsequent population of the Neighbor cache on the requesting host.

In order to enable functionality of an NDP refresh logic in IPv6, theARP refresh logic in IPv4 described herein would be modified beyond theuse of broadcast to accommodate the scoped multicast communications usedin NDP of IPv6 for Neighbor Solicitation. To this effect, the NDPrefresh logic would include the necessary mechanisms for the router tosubscribe to relevant host multicast trees used in IPv6 for distributionof Neighbor Solicitation. One embodiment of such functionality mayinvolve the use of the “all multicast” mode defined for ND Proxyinterfaces in RFC 4389, the contents of which are incorporated byreference in their entirety.

The “first ARP message” described herein (also referred to as a“gratuitous ARP message”) in IPv4 would be analogous to the unsolicitedneighbor advertisement in NDP of IPv6.

The “second ARP message” described herein (also referred to as a “proxyARP message”) in IPv4 would be analogous to a proxy neighboradvertisement in Neighbor Discovery Proxy (ND Proxy) in NDP of IPv6. Oneembodiment of such functionality may be implemented in compliance withRFC 4389 (ND Proxy).

Thus, the method shown in FIG. 4, in context of IPv6 could be summarizedas being modified to use NDP Simple Network Management Protocol version6 (SNMPv6) neighbor advertisement messages to update the neighbor cachesfor IPv6 hosts. The steps of the method can be summarized as follows:the detection of the moved host (402), copying packets from the sourcehost to the NDP refresh logic (404) and the update of the Neighbor Cacheentry for a remote destination host by sending an unsolicited neighboradvertisement message (406).

The method shown in FIG. 5, in context of IPv6 could be summarized asbeing modified only for steps 506 and 510 by using NDP SNMPv6unsolicited and proxy neighbor advertisements for IPv6 hosts. Step 506of the method would update the IPv6 neighbor cache at the source host bysending an unsolicited neighbor advertisement message when thedestination host is deemed to be remote. Step 510 of the method wouldupdate the IPv6 neighbor cache at the source host by sending a proxyneighbor advertisement to the source host when the destination host isdeemed to be local.

The method shown in FIG. 6, in context of IPv6 could be summarized asextracting the destination IPv6 address from a snooped packet (602),generating a neighbor solicitation SNMPv6 message for the extracteddestination IPv6 address on behalf of the edge router associated withthe moved host (604), simultaneously generating a neighbor solicitationSNMPv6 message for the extracted destination IPv6 address on behalf ofthe moved host (only if dynamic neighbor cache inspection is notenabled) (606), evaluating whether the neighbor solicitation sent in 604will timeout (608), in the event of a timeout deem the destination hostas remote and update the neighbor cache by sending an unsolicitedneighbor advertisement (610), if the neighbor solicitation in 604 isacknowledged with a valid neighbor advertisement, then the neighborcache on the source host should be updated on reception of the neighboradvertisement in response to the neighbor solicitation issued in 606.

The method shown in FIG. 7, is applicable in the context of IPv6 in thesame way that it is applicable in the context of IPv4 withoutmodification.

Variations and Implementations

Within the context of the disclosure, a network used herein represents aseries of points, nodes, or network elements of interconnectedcommunication paths for receiving and transmitting packets ofinformation that propagate through a communication system. A networkoffers communicative interface between sources and/or hosts, and may beany local area network (LAN), wireless local area network (WLAN),metropolitan area network (MAN), Intranet, Extranet, Internet, WAN,virtual private network (VPN), or any other appropriate architecture orsystem that facilitates communications in a network environmentdepending on the network topology. A network can comprise any number ofhardware or software elements coupled to (and in communication with)each other through a communications medium.

In one particular instance, the architecture of the present disclosurecan be associated with a service provider deployment. In other examples,the architecture of the present disclosure would be equally applicableto other communication environments, such as an enterprise wide areanetwork (WAN) deployment. The architecture of the present disclosure mayinclude a configuration capable of transmission controlprotocol/internet protocol (TCP/IP) communications for the transmissionand/or reception of packets in a network.

As used herein in this Specification, the term ‘network element’ ismeant to encompass any of the aforementioned elements, as well asservers (physical or virtually implemented on physical hardware),machines (physical or virtually implemented on physical hardware), enduser devices, routers, switches, cable boxes, gateways, bridges, loadbalancers, firewalls, inline service nodes, proxies, processors,modules, or any other suitable device, component, element, proprietaryappliance, or object operable to exchange, receive, and transmitinformation in a network environment. These network elements may includeany suitable hardware, software, components, modules, interfaces, orobjects that facilitate operations thereof related to the ARP/NDP table(cache) refresh described herein. This may be inclusive of appropriatealgorithms and communication protocols that allow for the effectiveexchange of data or information.

In one implementation, leaf nodes described herein may include softwareto achieve (or to foster) the ARP/NDP table refresh functions discussedherein, where the software may be executed on one or more processors tocarry out the functions. This could include the implementation ofinstances of programming logic and/or any other suitable element thatwould foster the activities discussed herein. Additionally, each of theleaf nodes can have an internal structure (e.g., a processor, a memoryelement, etc.) to facilitate some of the operations described herein. Inother embodiments, these functions for the ARP/NDP table refresh may beexecuted externally to the leaf nodes, or included in some other networkelement to achieve the intended functionality. Alternatively, leaf nodesmay include software (or reciprocating software) that can coordinatewith other network elements in order to achieve the functions related tothe ARP/NDP table refresh described herein. In still other embodiments,one or several devices may include any suitable algorithms, hardware,software, components, modules, interfaces, or objects that facilitatethe operations thereof.

In certain example implementations, functions related to the ARP/NDPtable refresh described herein may be implemented by logic encoded inone or more non-transitory, tangible media (e.g., embedded logicprovided in an application specific integrated circuit [ASIC], digitalsignal processor [DSP] instructions, software [potentially inclusive ofobject code and source code] to be executed by one or more processors,or other similar machine, etc.). In some of these instances, one or morememory elements can store data used for the operations described herein.This includes the memory element being able to store instructions (e.g.,software, code, etc.) that are executed to carry out the activitiesdescribed in this Specification. The memory element is furtherconfigured to store databases such as mapping databases to enablefunctions disclosed herein. The processor can execute any type ofinstructions associated with the data to achieve the operations detailedherein in this Specification. In one example, the processor couldtransform an element or an article (e.g., data) from one state or thingto another state or thing. In another example, the activities outlinedherein may be implemented with fixed logic or programmable logic (e.g.,software/computer instructions executed by the processor) and theelements identified herein could be some type of a programmableprocessor, programmable digital logic (e.g., a field programmable gatearray [FPGA], an erasable programmable read only memory (EPROM), anelectrically erasable programmable ROM (EEPROM)) or an ASIC thatincludes digital logic, software, code, electronic instructions, or anysuitable combination thereof.

Any of these elements (e.g., the network elements, etc.) can includememory elements for storing information to be used in achieving theARP/NDP table refresh described herein. Additionally, each of thesedevices may include a processor that can execute software or analgorithm to perform the ARP/NDP table refresh as discussed in thisSpecification. These devices may further keep information in anysuitable memory element [random access memory (RAM), ROM, EPROM, EEPROM,ASIC, etc.], software, hardware, or in any other suitable component,device, element, or object where appropriate and based on particularneeds. Any of the memory items discussed herein should be construed asbeing encompassed within the broad term ‘memory element.’ Similarly, anyof the potential processing elements, modules, and machines described inthis Specification should be construed as being encompassed within thebroad term ‘processor.’ Each of the network elements can also includesuitable interfaces for receiving, transmitting, and/or otherwisecommunicating data or information in a network environment.

Additionally, it should be noted that with the examples provided above,interaction may be described in terms of two, three, or four networkelements. However, this has been done for purposes of clarity andexample only. In certain cases, it may be easier to describe one or moreof the functionalities of a given set of flows by only referencing alimited number of network elements. It should be appreciated that thesystems described herein are readily scalable and, further, canaccommodate a large number of components, as well as morecomplicated/sophisticated arrangements and configurations. Accordingly,the examples provided should not limit the scope or inhibit the broadtechniques of the ARP/NDP table refresh, as potentially applied to amyriad of other architectures.

It is also important to note that the steps in the FIGS. 4-7 illustrateonly some of the possible scenarios that may be executed by, or within,the ARP/NDP refresh logic described herein. Some of these steps may bedeleted or removed where appropriate, or these steps may be modified orchanged considerably without departing from the scope of the presentdisclosure. In addition, a number of these operations have beendescribed as being executed concurrently with, or in parallel to, one ormore additional operations. However, the timing of these operations maybe altered considerably. The preceding operational flows have beenoffered for purposes of example and discussion. Substantial flexibilityis provided by the ARP refresh logic in that any suitable arrangements,chronologies, configurations, and timing mechanisms may be providedwithout departing from the teachings of the present disclosure.

It should also be noted that many of the previous discussions may implya single client-server relationship. In reality, there is a multitude ofservers in the delivery tier in certain implementations of the presentdisclosure. Moreover, the present disclosure can readily be extended toapply to intervening servers further upstream in the architecture,though this is not necessarily correlated to the ‘m’ clients that arepassing through the ‘n’ servers. Any such permutations, scaling, andconfigurations are clearly within the broad scope of the presentdisclosure.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims. In order to assist the UnitedStates Patent and Trademark Office (USPTO) and, additionally, anyreaders of any patent issued on this application in interpreting theclaims appended hereto, Applicant wishes to note that the Applicant: (a)does not intend any of the appended claims to invoke paragraph six (6)of 35 U.S.C. section 112 as it exists on the date of the filing hereofunless the words “means for” or “step for” are specifically used in theparticular claims; and (b) does not intend, by any statement in thespecification, to limit this disclosure in any way that is not otherwisereflected in the appended claims.

Although the claims are presented in single dependency format in thestyle used before the USPTO, it should be understood that any claim candepend on and be combined with any preceding claim of the same typeunless that is clearly technically infeasible.

What is claimed is:
 1. A method to assist communication of a sourcehost, the method comprising: receiving a learn notification; determiningif the learn notification is bound to an address; in response to thelearn notification being bound to the address, determining if theaddress is in a database; in response to the address being in thedatabase, establishing no new host move; and in response to the addressnot being in the database, confirming the new host move.